The present invention relates to an electronic mail message system and more particularly to a system for attaching information about mail messages to the mail messages.
Electronic mail ("e-mail") is the application which drives users to the Internet and other on-line networks. Each year, billions of messages are transported between friends, business acquaintances, junk e-mailers, members of mailing lists and even total strangers. On the Internet, electronic mail messages generally conform to the consensually agreed upon standards. These standards are set out in documents referred to as "Requests For Comments" or RFC's. The RFC's applicable to e-mail messages include RFC 822 and others.
In general, an e-mail message is made up of a header section containing a plurality of header fields and a message body. Each header field has a field name and a field value, separated by a delimiter between the field name and the field value and a delimiter between header fields. For example, the header field "From: name@domain" has a field name of "From:" and a value of "name@domain". This particular header field indicates that the message is from a person or machine known at the host machine "domain" as "name". Other fields provide other information about the message or the author.
At minimum, a message should have "From:", "To:", "Subject:" and "Date:" header fields. Often, header fields are added to a message to assist with understanding the message or troubleshooting transmission errors. For example, a "Message-Id:" or "Received:" header field could be used to diagnose transmission problems if messages are not being received correctly. A "Received:" header field is typically added at each node which receives and forwards the message, so that when the message finally arrives at its destination, it has a log of how it got there. If the message body is not simple text, it might include a "Content-Type:" header field to indicate how the message should be interpreted.
Since a mail message can be transported with no more context than the e-mail address of the sender and the e-mail address of the receiver, the recipient of the message might not recognize the sender, even where they know each other well. For example, even if Alice Jones and Bob Benson talked frequently, Alice might not recognize a message from "bb1023@smtp.dgrlu.edu". The sender can avoid this problem in several ways.
If the sender, Bob, has a say in what name is assigned to him, he can select a better name, such as "bob_smith". Administrators of large systems will not always allow Bob to have whatever name he wants, either because the names must comply with some consistent naming scheme or the desired name has already been assigned to someone else. This problem has been addressed by the RFC's in that a sender's full name, which need not be unique or easily parsable, can be included in a header field. An example of this is the header field "From: Bob Smith &lt;bb1023@smtp.dgrlu.edu&gt;".
The use of full name would be sufficient to provide Alice with a context for the message, since Alice knows Bob, but would not help if Alice didn't know a Bob Smith. If desired, Bob can include an "Organization:" header field to indicate an association with which Alice might be familiar. If the sender's company handles all of the outgoing mail messages, the company's host machine might add the "Organization:" header field to each outgoing message to facilitate this process.
Where the sender cannot control the sender's e-mail address or the headers used, the sender can include a "signature block" at the end of his or her message. By convention, the signature block is four lines or less giving the context of the sender. A typical signature block contains the sender's full name, company name, telephone number, address, etc. Of course, since the signature block is free form text, many senders get creative and include long signature blocks which might include character-based artwork, quotes, jokes, disclaimers, etc.
Context is important in a message where the communication depends on where the sender and recipient are physically located. If a merchant offers goods or services by e-mail, recipients might need to know where the merchant is physically located before deciding whether that merchant can be patronized as a practical matter. By remembering to include an address, the merchant can provide the necessary context. Many different kinds of context are needed, but the need for physical location context is made more important by the fact that the Internet is a global network.
One solution to the problem of context is to include a standardized block of data with each message, i.e., an electronic business card. Such a scheme is described in an Internet Draft entitled "An Application/Directory MIME Content-Type Electronic Business Card Profile" (file name: draft-ietf-asid-mime-vcard-00.txt). Therein, a type of message attachment referred to as a "vCard" is described. A vCard can be attached to an e-mail message, or can be used outside of a mail system, to present a user's "business card" data in a standardized format. "Business card" data is that data which normally appears on a business card, such as name address, telephone number, alternate number, e-mail address, picture, etc., as well as other identifying information which might be added to a business card when it becomes an electronic business card, such as a video or audio clip. To provide context, the sender of a message would attach his or her vCard to the message. The vCard could then be viewed by the recipient.
One disadvantage of many of the above methods of providing sender context is that the sender must use them, otherwise no context is provided. Even if the context was provided in every message, network bandwidth would be wasted sending the extra context information repeatedly. What is needed is a system for obtaining context for a message without requiring the continual transport of this context information and without requiring that a context-providing action be taken by the sender each time.